-
Notifications
You must be signed in to change notification settings - Fork 188
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
'Edit this page' option added #159
Conversation
✅ Deploy Preview for boring-fermat-22cb64 ready!
To edit notification comments on pull requests, go to your Netlify site settings. |
Hey @olayway your code readability is super. 👏 Regarding pages, the concept here I'm thinking is that anyone is able to contribute here in any way even for small things like spelling mistakes (this has happened) or maybe errors in linking to wrong sites, etc. This is after all a wiki. 😄 I think we should keep it as open as possible (for eg. see cloudflare docs). Except for the homepage, I guess all can work. what do you think ? comments on updated pr description: direct commits are only possible by members of repo. Non-members have to create a pull request by default after making changes. ie, If someone makes an edit to any page, they have to click the create pull request button on GitHub even if the repo is public (since they are not owner or member, unless otherwise I'm mistaken). Note: btw why did package-lock.json add ~5800 lines ? is that normal ? |
Thank you @khalilcodes ! It's very nice to hear it 😊.
You're right and I totally agree with the idea of this project being as open to any public contribution as possible. I think it should work like in Wikipedia - anybody can contribute. However, as far as I'm aware, on Wikipedia, there also are certain restricted parts/pages that are not subject to external (i.e. not coming from Wikipedia Foundation) conribution. In our case, I imagine these would be parts of the web3 project tightly coupled with the LifeItself branding (e.g. page design) and educational activity (webinars, podcast notes etc.). However, if the idea is to hand over the whole project to people so it naturally evolves according to people's needs - then I guess we can keep the whole project fully open.
You're right 🤦♀️. In this case, do you think I should add the prompt 'Edit this page' to all the pages? If so, I'll just make a small tweak in the code and we could merge it.
I was trying to wrap my head around it yesterday as well 😅. And the changes are bizarre, like adding |
Thanks @olayway for the review on comments. For now I think let's just merge this and if required we can discuss again and reopen the issue. 👍 Don't really know why that happens with package-lock.json 🤷♂️ but maybe we can research on that later too. |
Changes
Notes
I've arbitrarily added this option only for /guide, /claims/[...] and /concepts/[...] pages since it didn't make much sense to me to add it for non-wiki-like pages (e.g. notes from our podcasts which I thought should not be subject to external user's changes). However, not adding this button on a particular page doesn't really prevent a user from finding it directly to GitHub and committing changes.
Content protection
There is no way to create protection rules on GitHub for selected paths or files within a project = protection rules can only be set on a whole branch (but I may be wrong). Thus there seem to be a few options we could consider (I'm no expert in this subject so please take it with a grain of salt):
Solution A
Making the
main
branch protected and allowing commits only through PRs that require reviews from someone from Life Itself.Solution B
Making the
main
branch protected and creating a separate non-protected branch, e.g.contributions
that anyone could commit to.contributions
) up-to-date withmain
branch, so that the content the user sees on the webpage (sourced frommain
) and intends to edit is the same he will see when clicking on 'Edit this page' (redirects to the page file oncontributions
branch) are in constant alignment.main
(after someone from Life Itself has pushed some changes) tocontributions
. However, there may occur some conflicting changes in this case in which such pull would fail, and further action would be required.Solution C (The best option in my opinion)
Creating an unprotected branch e.g.
contributions
and creating a submodule of web3 repo, that would point to itself but to its unprotected branch (contributions
). So, we would have:contributions
- unprotected branch with:main
- protected branch with:contributions
branch of the repoFlow:
contributions
branch:main
branch we would do sth like this:Reference: https://stackoverflow.com/a/35307501
Closing #76